Internet Protocol version 6 (IPv6) offers interconnection of almost every physical object with the Internet. This leads to tremendous possibilities to develop new applications, such as home automation and home security management, lighting systems, smart energy monitoring and management, item and shipment tracking, surveillance and military, smart cities, health monitoring, logistics monitoring and management. With the introduction of Internet Protocol (IP) version 6 over low-power wireless personal area networks (6LoWPAN) in wireless sensor networks (WSNs), resource constrained devices can be connected to the Internet. This hybrid network of the Internet and the IPv6 connected constrained devices form the so-called “Internet of Things” (IoT). Unlike the Internet where devices are mostly powerful and unlike typical WSN where devices are mostly resource constrained, the things in the IoT are extremely heterogeneous. An IoT device can be a typical sensor node, a light bulb, a microwave oven, an electricity meter, an automobile part, a smartphone, a personal computer (PC) or a laptop, a powerful server machine or even a cloud.
Due to the low-powered and lossy nature of wireless networks in the IoT, the connection-less User Datagram Protocol (UDP), instead of stream-oriented Transmit Control Protocol (TCP), is mostly used in the IoT. The synchronous Hyper Text Transfer Protocol (HTTP) is designed for TCP and is infeasible to use in the UDP-based IoT. Therefore, the Constrained Application Protocol (CoAP), a subset of HTTP is being standardized as a web protocol for the IoT. CoAP is tailored for constrained devices and for machine-to-machine communication. Furthermore, although Internet Protocol Security (IPsec) can be used in the IoT it is not primarily designed for web protocols such as HTTP or CoAP. For web protocols the Transport Layer Security (TLS) or its predecessor Secure Sockets Layer (SSL) is the most common security solution. However, the connection-oriented TLS protocol can only be used over stream-oriented TCP that is not the preferred method of communication for smart objects. Due to lossy nature of low-power wireless networks it is hard to maintain a continuous connection in 6LoWPAN networks.
An adaptation of TLS for UDP is called Datagram TLS (DTLS). DTLS guarantees end-to-end (E2E) security of different applications on one machine by operating between transport and application layers. DTLS in addition to TLS that provides authentication, confidentiality, integrity, and replay protection, also provides protection against Denial of Service (DoS) attacks with the use of cookies. Though DTLS provides application level E2E security, it can only be used over the UDP protocol. The secure web protocol for the IoT, Secure CoAP (CoAPs), mandates the use of DTLS as the underlaying security solution for CoAP. Therefore, it is necessary to enable DTLS support in the IoT, e.g., for security issues sich as bootstrapping. The term “bootstrapping” is derived from its use since about 2005 in the 6LoWPAN working group of the IETF. It can be defined as the process of configuring a node to enable it to participate in normal network operation. But may be more strikingly, in general usage the process of bootstrapping means setting up a complicated software environment in several steps, starting from something very primitive (such as a diode-matrix ROM bootstrap in early computing). Transferring this notion to security bootstrapping, and combining it with the above definition, it might stand for the setup of a robustly secure node configuration using some primitive initial keying materials and security procedures.
During DTLS handshake, a client and server agree on various parameters used to establish a connection's security. As an example, in IP based lighting networks, DTLS handshake is used to commission lighting devices during commissioning.
FIG. 1 shows a signalling diagram with typical DTLS handshake with certificate between a client (C) and a server (S). The numbers in brackets after each message part indicate the individual lengths of these parts in Bytes.
To set up a new connection and negotiate the security parameters a handshake protocol is used. The client initiates the handshake by sending a ClientHello message to the server. This message contains supported cipher suites, hash and compression algorithms and a random number. The server is supposed to respond with a ServerHello, which contains the cipher suite and algorithms the server has chosen from the ones the client offered and also a random number. Both random numbers will be used, among other data, to calculate the master secret. The server may continue with a server certificate message including its certificates to authenticate itself, if necessary. In that case it can also send a CertifcateRe quest message, to provoke the client to authenticate, too. For some cipher suites additional data may be necessary for the calculation of the secret, which can be send with a ServerKeyExchange message. Since the last three messages mentioned are optional, a ServerHelloDone message indicates when no more messages follow from the server.
This part of the handshake is a problem with connection-less transport protocols, because there is no transport connection setup necessary and an attacker could just send many ClientHellos to a server. This could be used for a denial of service (DOS) attack against the server, which will start a new session, thus allocating resources, for every ClientHello, or against another victim by redirecting the much larger response of the server to it, thus multiplying the attacker's bandwidth. To prevent this issue, DTLS uses an additional handshake message, called HelloVerifyRequest. It is sent in response to the ClientHello message and contains a so-called cookie of arbitrary data, preferably signed. The server will only send this message without allocating any resources. The client then has to repeat with a ClientHello* message with the cookie attached. If the cookie can be verified, hence the signature, the server knows that the client has not used a faked address, and since the HelloVerifyRequest message is small and has to be answered before the server sends any more data, no DOS attacks are possible anymore. After this verifcation the handshake will be continued as before.
After the ServerHelloDone message, the client has to send its certifcates with a ClientCertifcate message if the server requested authentication. This is followed by a ClientKeyExchange message, which contains its public key or other cryptographic data, depending on the cipher suite used. Also depending on the cipher suite is whether a CertifcateVerifY message to verify a signed certifcate has to be sent. At this point both peers have enough information to calculate the master secret. Thus, the client sends a ChangeCipherSpec message to announce that the negotiated parameters and the secret will be used from now on. Its last message is the Finished message, which contains a hash calculated over the entire handshake and is encrypted already. The server concludes the handshake by also sending the ChangeCipherSpec and Finished messages.
Since DTLS handshake aims to initiate the security connections, it is very critical to have a successful DTLS handshake to start communication. The performance of DTLS handshake, such as delay and successful rate, very much depends on the network status such as congestion, wireless loss, packet loss rate, etc. It also depends on the security modes of the DTLS handshake, for example, DTLS with Pre-Shared Key (PSK), raw public key or certificates since the different modes have different number of packets to be transmitted.
The delay increases with increasing packet loss rate. For the DTLS-certificate mode where more packets are needed to be transmitted, the delay increase faster than other modes. The PSK with return acknowledgement mode sends one packet once and waits for the reply of acknowledgement. If there is no ACK returned, the packet will be sent again. Consequently, the delay of this mode is much bigger than the other PSK methods.
Since DTLS handshake aims to initiate security connections, it is very critical to have a successful DTLS handshake to start communication. As DTLS handshake is used in UDP communication, the packets for DTLS handshake can be lost in the transmission. To ensure reliable receiving, a DTLS with acknowledgement (ACK) can be used, where an ACK message is generated and sent by the receiver. However the ACK packet can also be lost. When there are some sorts of packet loss, such as wireless loss or congestion loss, the handshake delay can be prolonged. When there are more messages to be sent, such as certificates, etc, the delay can be much bigger which will lower the success rate of handshake. Hence, DTLS with acknowledgement generates more delay especially when transmitting more packets. Furthermore, channel packet loss and loss rate are not easy to measure.
Thus, current DTLS handshake modes or strategies have different performances in different packet loss rates. The causes of packet loss also have significant impacts on the DTLS handshake. It is therefore necessary to take into account the causes of packet loss such as congestion loss and wireless loss to achieve better success rate of DTLS handshake and improve the performance of DTLS handshake. Especially for DTLS handshake with certificates, there are more packets to be exchanged during DTLS handshake. The packet loss modes and packet loss rate have big impact on the success rate of DTLS and handshake delay.
This invention aims to propose a dynamic ACK to shorten the delay and use the ACK to estimate the packet loss and adjust the transmission strategy.